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WO 00/30401 PCT/US99/26902 
METHOD AND APPARATUS FOR SUPPORT OF IP DIFFERENTIATED SERVICE OVER MPOA 

1 

2 CROSS REFERENCE TO RELATED APPLICATIONS 

3 This application claims benefit of co-pending U.S. provisional application 

4 Serial No. titled "Method and Apparatus for Support of IP 

5 Differentiated Services over MPOA" filed November 1 3, 1 998. 
6 

7 BACKGROUND OF THE INVENTION 

8 Developing Quality of Service (QoS) capabilities for Internet Protocol (IP) 

9 has been an active work area at the Internet Engineering Task Force (IETF) as 

10 well as by many other entities. The IETF has identified two alternative 

11 approaches, Integrated Services (Int-Serv) and Differentiated Services (Diff- 

12 Serv) as the most promising solutions to address different QoS needs. 

13 The IETF has been addressing the service mappings between Int-Serv 

14 and individual link layers, including ATM (see, e.g., L. Berger, "RSVP over ATM 

15 Implementation Guidelines", IETF RFC 2379, August 1998 and M. Garrett and 

16 M. Borden, "Interoperation of Controlled-Load Service and Guaranteed Service 

17 with ATM", IETF RFC 2381, August 1998.) More recently, a proposal was 

18 accepted by the ATM Forum to commence work in the Traffic Management 

19 working group on enhancements for supporting both Diff-Serv and IEEE 802.1 D 

20 (see, e.g., Marty Borden et al., "Enhancements to Support IETF Diff-Serv and 

21 IEEE802.1D", ATM Forum, atmf/98-07B9R1 , Oct. 1998.) 

22 Unfortunately, neither of these proposals are intended to address support 

23 of Diff-Serv using MPOA. Diff-Serv flows over standard MPOA do not receive 

24 proper service because, as will be explained in greater detail below, shortcut 

25 flows to a given destination are forwarded over the same ATM connection. 
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1 These shortcuts bypass Intermediate routers that would otherwise be 

2 responsible for providing different services to different flows. Therefore, it is 

3 necessary to distribute policy information to the various MPOA clients. The 

4 policy information defines how packets should be classified into Diff-Serv 

5 classes. 

6 These proposals further do not adequately address flow detection by the 

7 MPOA clients 

8 Further, the proposals do not adequately address discovery of Diff-Serv 

9 capabilities of MPOA devices. 

10 What is needed in order to effectively implement Diff-Serv in a joint 

11 IP/ATM environment Is a method and apparatus for providing distribution of 

12 policy information to MPOA clients, method and apparatus for addressing flow 

13 detection requirements of MPOA clients, and method and apparatus providing 

14 discovery of Diff-Serv capabilities of MPOA devices. 

15 Before addressing solutions proposed by the present invention, it is 

16 worthwhile to provide some background on MPOA and Diff-Serv. 

17 MPOA 

18 MPOA establishes direct shortcuts across an ATM network for forwarding 

19 Internetwork Layer packets. Shortcuts take advantage of the ATM topology and 

20 can be more efficient than hop-by-hop router forwarding. This Is illustrated by 

21 Figure 1 which shows logical components and packet flows for an MPOA 

22 network. As can be seen, in a network not implementing MPOA, packet flow 

23 follows the logical ELAN connectivity route in order to transport a packet from 

24 edge device 101 to edge device 102. The actual route is shown (without MPOA 
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1 shortcuts) is shown as passing through routers 104 and 105. The route, after 

2 the shortcut is established using MPOA. is represented by the line passing 

3 through the ATM network. 

4 MPOA requires six distinct operations: (1) configuration, (2) discovery, (3) 

5 flow detection, (4) target resolution, (5) connection management and (6) data 

6 transfer. MPOA devices obtain configuration via a LAN Emulation Configuration 

7 Server (LECS). Each of these operations will be discussed in greater detail 

8 below. 

9 MPOA configuration information, as well as LANE configuration 

10 information, is returned in the LAN Emulation (LANE) configuration process. The 
U MPOA configuration information is needed to initialize and control other MPOA 

12 operations. MPOA configuration information consists of the internetwork 

13 protocols monitored by the MPOA device, timeouts, and thresholds. 

14 Discovery is the process by which MPOA components learn of each 

15 other's existence. Additional information is included in LANE control frames to 

16 permit automatic detection of MPOA components, thus eliminating some 

17 configuration and making the environment more dynamic. Discovered 

18 information consists of the type of device (either an MPOA Client which will be 

19 referred to as a "MPC U or a MPOA server referred to as a "MPS") and the 

20 addresses used by the device. 

21 Flow detection is performed by MPCs to identify streams of traffic, or 

22 flows, that should be transmitted over a shortcut. The default definition of a flow 

23 in MPOA is a sequence of packets to a particular internetwork destination that 
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1 satisfies a certain transmission rate. Other (unspecifi d) flow definitions are 

2 permitted. 

3 After a flow is detected, target resolution is the process by which an MPC 

4 determines the mapping between an internetwork address and an ATM address. 

5 A resolution request is forwarded along the routed path from the Ingress MPC (I- 

6 MPC) to the egress MPC (E-MPC), which returns a response indicating the ATM 

7 address to be used for a shortcut for that destination. Additional information, 

8 including the encapsulation for the shortcut packets, is also returned in the 

9 response. 

10 Connection management then establishes a Virtual Circuit Connection 

1 1 (VCC) to this address for the purposes of transmitting packets to the destination. 

12 The default QoS for MPOA shortcuts is best effort Unspecified Bit Rate (UBR) 

13 (although other types of QoS are permitted). 

14 Data transfer refers to the transmission of packets over the shortcut. 

15 These packets bypass all intermediate routers, taking a more direct path (the 

16 shortcut) over the ATM network. MPOA v1.0 was developed to support a best- 

17 effort service at the internetwork layer. Thus, it lacked the specific features 

18 necessary to support QoS at the internetwork layer, such as those characterized 

19 by Diff-Serv and Int-Serv. 

20 pjffemnliated Service 

21 Diff-Serv differs from Int-Serv in a number of ways which have 

22 implications for MPOA and which have been heretofore unaddressed. In 

23 particular: 
24 
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1 ■ Service categories in th Diff-Serv model are relative, or qualitative, in that 

2 the aggregate of packet flows with the same Diff-Serv Code Point (DSCP) is 

3 subject to the same Per-Hop Behavior (PHB), which may not involve explicit 

4 resource commitment per flow. 
5 

6 • In Diff-Serv, the end-systems need not explicitly signal the packet 

7 classification and service requirement to the network. This is unlike the use 

8 of PATH and RESV messages in Resource Reservation Protocol ("RSVP") 

9 which is used to support Int-Serv. Thus, RSVP over MPOA will require 

10 treatment of these signaling messages, while Diff-Serv does not. 
11 

12 ■ Diff-Serv uses an implicit, policy-based model. Diff-Serv services are 

13 constructed by a combination of per hop behaviors (PHBs) and edge 

14 behaviors. A Diff-Serv domain consists of interior and edge nodes, with most 

15 of the complexity at the edge nodes. Interior nodes examine the DS field 

16 only (known as Behavior Aggregate classifier) and perform the appropriate 

17 PHB. In addition to PHBs, edge nodes may be responsible for classification, 

18 metering, policing, marking, and shaping (among other functions). The edge 

19 actions are determined based on the value of a combination of one or more 

20 header fields. The rules for each service are set through administrative 

21 policy. Policy can be distributed to Diff-Serv nodes via a policy protocol. 
22 

23 The IETF Differentiated Services (DS) Working Group is developing a way of 

24 providing Internet Protocol (IP) QoS. DS uses the TOS octet In IPv4 and the 
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Traffic Class octet in IPv6, together referred to as the DS field, to indicate the 
QoS class that an IP packet belongs to. This enables service discrimination 
without requiring per-flow states and signaling at routers. 

A DS code point is a specific pattern of the DS field. Associated with a DS 
code point is a per-hop behavior (PHB). which Is the packet forwarding treatment 

6 that a DS-compliant node should apply at its output interface to packets marked 

7 with this DS code point. 

8 A DS domain consists of interior and edge nodes, with most of the complexity 

9 at the edge nodes. Interior nodes examine the DS field and perform the 

10 appropriate PHB. In addition to PHBs, edge nodes may be responsible for 

11 classification, metering, policing, marking, and shaping (among other functions). 

12 A DS edge device performs classification by inspecting the header of each 

13 packet and considering it part of a specific group or class. An edge device uses 

14 metering to measure the data rate in a particular class. Policing is the means by 

15 which a specific data rate is enforced. Marking is when a DS edge device fills in 

16 the DS field of a packet based on the class to which the packet belongs. Finally, 

17 an edge device performs shaping by transmitting packets at specific rates for 

18 various traffic classes. A particular edge device may be required to do any 

19 subset of these functions (including none). 

20 DS services are constructed by a combination of per-hop behaviors and edge 

21 behaviors. The rules for each service are set through administrative policy. DS 

22 policy has several aspects. All nodes must know the relationship between the 

23 DS field of a packet and the appropriate PHB. When transmitting over links with 

24 QoS abilities such as ATM, this may include a mapping between the IP DS code 

25 point and specific link layer QoS parameters. Additionally, edge nodes must 

26 know the rules for packet classification, metering, policing, marking, and shaping. 
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1 Policy is distributed to OS nodes via a policy protocol. The exact form of tho 

2 protocol is as yet undefined. 

3 One prevalent set of possible OS sen/ices is soft or relative QoS for 

4 aggregate flows, which is referred to here as a Class of Service (CoS) 

5 differentiation. Contrary to the Resource Reservation Protocol (RSVP) 

6 approach, flow identifications are not signaled explicitly by the end systems but 

7 are defined by policy. For example, an output interface may contain a set of 

8 parallel queues that are served based on a Weighted Round Robin (WRR) 

9 scheme. Each DS code point is then associated with one queue with a serving 

10 weight. Edge devices mark packets according to configured policy, so that all 

11 packets with the same DS code point share the same forwarding queue and are 

12 entitled to its bandwidth share at each output interface. This is just one possible 

13 DS interpretation, 

14 Unfortunately, if DS edge and per-hop behaviors are only implemented in routers, 

15 then packets forwarded over MPOA shortcuts bypass the routers and may not receive 

16 the proper sen/ice. 
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BRIEF SUMMARY OF THE INVENTION 
A method and apparatus providing for extensions to MPOA to 
accommodate Diff-Serv over MPOA is described including: (a) distribution of 
policy, (b) flow detection and (c) discovery of diff-serv capabilities of MPOA 
clients. 

These and other aspects of the present invention will be better described 
with reference to the detailed description. 
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1 BRIEF DESCRIPTION OF THE DRAWINGS 

2 Figure 1 is an overall diagram of a network as may implement an 

3 embodiment of the present invention. 
4 

5 
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1 DETAILED D ESCRIPTION OF EMBODIMENTS OF THE INVENTION 

2 As was discussed in the background section, implementing internet 

3 protocol (IP) differentiated services (Diff-Serv) using Multiprotocol Over ATM 

4 (MPOA) has heretofore not been addressed. 

5 The present invention introduces extensions to MPOA in the following 

6 areas in order to provide for Diff-Serv over MPOA; (a) distribution of policy, (b) 

7 flow detection and (c) address discovery. 
8 

9 Policy Distribution 
10 

1 1 Differentiated Services use policy to determine to control packet flows. In 

12 the described embodiment, it is assumed that policy information is distributed to 

13 all routers (e.g., router 104 and 105 in figure 1) in the differentiated service 

14 domain. This implies that policy is distributed to all MPOA servers (MPSs). 

15 However, as has been stated, within the MPOA service domain, the 

16 responsibility for forwarding packets is distributed between MPSs 104, 105 and 

17 MPOA clients (MPCs) 101, 102. Thus, in order to provide per hop behavior 

18 (PHB) service, the MPCs as well as the MPSs must have access to the DS 

19 policy. 

20 For interior Diff-Serv nodes, the policy consists of determining the 

21 resource allocation and mapping the DS field of a packet into specific ATM QoS 

22 parameters. Edge nodes have additional policy considerations. DS policy for 

23 edge nodes can be expressed as a collection of filter specifications. A filter 

24 specification is a combination of filter criteria and filter actions. Filter criteria 

25 define how packets should be classified. They are generally based on certain 

26 header fields (e.g., source IP address, destination IP address, carried protocol, 
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source port, and destination port). Filter actions define how packets should b 
marked and treated by DS edges. 

What is proposed hare is to allow the DS routers, in their roles as MPSs, to 
distribute policy to MPCs. When a router is acting as an interior DS device, it 
must distribute the resource allocation and the mappings between DS code 
points and ATM QoS parameters to its MPCs. The policy may be distributed by 
any of a number of methods including, for example: 

1 . The MPC can run the policy distribution protocol to receive policy, similar to 
an MPS. 

2. The mappings can be distributed during configuration via the LECS. 

3. The mappings can be distributed during discovery. 

4. A new request/response/trigger frame between MPCs and MPSs can be 
defined to distribute this information. 

The first method greatly increases the number of policy clients, and may 
affect the scalability of the policy distribution protocol. However, this method 
advantageously requires no extensions in the behavior of any other LANE or 
MPOA component. 

In methods (2) through (4), new type length values (TLVs) fields are defined 
to carry the mappings. The TLVs are carried in the appropriate LANE or MPOA 
control frames. The second method requires some out-of-band mechanism to 
distribute policy to the LANE Configuration Server, which then distributes it to the 
MPCs. The third method is dynamic, but may be limited by the size of the LANE 
control frame (which at most 1516 octets). The final method is the most generic, 
but requires a new type of MPOA control frame, a policy request/response 
frame. With the last method, the MPC must request the mappings after 
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discovering an MPS and before establishing any shortcuts. Methods (3) and (4) 
have the advantage that the distribution is dynamic (i.e., the mappings can 
change and the changes are automatically propagated to the MPCs). 

When an MPS Is acting as an edge router, It must also distribute filter 
specifications to MPCs. Filter specifications are required so that the MPC can 
properly function as a DS edge device. Since shortcut traffic bypasses the 
MPS, which is also the DS edge router, the MPC must perform the classification, 
marking, metering, policing, and shaping functions on behalf of the MPS for 
packets traversing the shortcut. This proposal defines the 4 methods above to 
distribute filter specifications to MPCs. 

The distribution of filter specifications differs from the distribution of the 
mappings between DS code points and ATM QoS parameters in several 
aspects. First, the sheer amount of information In the collection of filter 
specifications is much greater. There are a limited number of DS code points, 
but the number of possible filter specifications is much greater. Second, it is 
unlikely that a single MPC will need all of the filter specifications at any time. An 
MPC needs only those filter specifications that apply to traffic being forwarded by 
that MPC. Third, filter specifications are generally more dynamic and changes in 
filter specifications must be propagated in a timely fashion. 

Filter specifications can be classified into two categories: destination-specific 
and destination-independent. Destination independent filters apply to more than 
one destination IP address. It is important that an MPC have all of filter 
specifications that apply to a particular destination before the MPC forwards 
traffic for that destination over a shortcut, so that the appropriate DS behavior 
can be applied to the shortcut traffic. 
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1 Methods (1) through (3) can be used to distribute some or all filter 

2 specifications to th_ MPC. However, method (4) permits filter specifications to 

3 be distributed to MPCs on an as-needed basis as long as the following 

4 requirements are met: 

5 • The MPC must request all filters that apply to a particular destination before 

6 deciding to establish a shortcut to the destination. 

7 • The MPS responds to fitter requests by returning the applicable filter 

8 specifications. The set of applicable filter specifications could be empty. 

9 • The MPS may generate a filter trigger to an MPC. A filter trigger causes the 

10 MPC to initiate a filter request for the filter specifications indicated by the 

1 1 trigger* The trigger may be used to Indicate a change or update in policy. 

12 These requirements can be satisfied in a variety of ways: 

13 • In some implementations, this may result in an MPC requesting all 

14 destination independent filters shortly after discovering an MPS. 

15 • in some implementations, this may result in an MPC requesting all filters that 

16 apply to a particular destination after initiating flow detection but before 

17 initiating a resolution request. The MPC may signal that it wants all filters that 

18 apply to a target (including destination independent filters), or only that it 

19 wants those filters that apply to the specific destination. 

20 Other implementations satisfying the requirements are possible. The key 

21 point is that the MPC must be guaranteed to have all applicable filter 

22 specifications before it attempts to establish a shortcut. The applicable 

23 specifications are requested by the MPC, and the MPC may be prodded to 

24 request certain filter specifications by the MPS. 
25 
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1 MPOA Configuration and Discovery 

2 MPOA components discover each other using extensions to the LANE 

3 LE_ARP protocol that carry information such as the MPOA device type and ATM 

4 address. In the described embodiment, new TLV(s) are added to the LE_ARP 

5 , messages to indicate the DS capabilities of the device. The absence of the 

6 TLV(s) indicates that the component does not support any of the DS extensions. 

7 An MPC or MPS capable of the DS extensions will not attempt to use them with 

8 an MPS or MPC not capable of the extensions. This provides for interoperability 

9 with current MPOA implementations. 

10 In the described embodiment, TLVs can be used to indicate support of the 

11 following DS capabilities: (a) DS parameter distribution, (b) filter specification 

12 distribution, (c) whether policy distribution is enabled and (d) whether an MPS is 

13 a DS edge router as well as other capabilities. In certain embodiments, 

14 indicating other DS abilities via discovery TLVs is also possible. 

15 

16 Flow Detection 

17 In MPOA v1.0, the detection of shortcut-eligible IP flows is, by default, based 

18 on the number of packets sent to a particular destination through a particular 

19 MPS in a specified period of time. In the described embodiment, the default flow 

20 detection is extended to be the number of packets with a particular DS code 

21 point sent to a particular destination through a particular MPS in a specified 

22 period of time. Other algorithms for flow detection may be utilized' in certain 

23 embodiments but the flow detection algorithm should use the DS field in the 

24 definition of a flow. In particular, ingress cache entries in MPCs must be 

25 extended to monitor the DS field. 
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1 It is worthwhile to describe two embodiments of the d fault flow detection 

2 algorithm. In the first option, OS-sensitive flow detection (if using method (1) or 

3 (2) of the previous section) can be initiated upon the creation of the ingress 

4 cache entry (i.e. on the detection of the first packet with a particular destination 

5 address, MPS, and DS field). In the second option, in which the l-MPC does not 

6 have the filters associated with a given destination and hence must obtain the 

7 filters dynamically, the l-MPC performs a two-stage flow detection. In the first 

8 stage, the l-MPC counts the number of packets with a particular destination 

9 address and MPS. When this count exceeds a threshold, the MPC initiates a 

10 filter request. Upon receiving the applicable filter specifications, the l-MPC can 

1 1 perform flow detection including the DS field, based on the filter specifications 

12 returned. 

13 Other default flow detection algorithms may be utilized without departure from 

14 the present invention. 

15 Assume that an MPC is performing the edge device functions for a particular 

16 MPS and that it has requested and received the filter specifications applicable to 

17 a certain packet. When another matching packet arrives at the l-MPC, it is 

18 matched against the filter specifications to determine its DS code point. The 

19 result, together with the destination address and MPS, is used to match with the 

20 ingress cache entries, or to create a new entry if one does not already exist. If a 

21 match Is found and a shortcut VCC of the appropriate QoS is available, the I- 

22 MPC applies the corresponding filter actions before forwarding the packet over 

23 the shortcut. Otherwise, a flow detection counter Is Incremented. If the 

24 configured flow threshold is exceeded, a shortcut with the appropriate QoS class 

25 is initiated. If the MPC is not performing edge router functions, the DS code 

26 point of the packet is used to match the ingress cache entry. 

27 
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Target Resolution 

Through target resolution, an l-MPC obtains the ATM address of the E-MPC 
for the destination IP address. MPOA provides for obtaining this information. 

However, additional information, such as encapsulation and tagging, may be 
conveyed through target resolution. For example, the E-MPC needs to know the 
DS code point of the flows that prompt the resolution process in the following 
cases: 

(1) When different DS codepoints need to be mapped to different egress 802. 1D 
user_priority markings in the DLL header. In this case, the layer 2 
encapsulation at the egress is dependent on the DS codepoint. 

(2) When E-MPC uses different MPOA tags for different DS codepoints to aid 
egress queue selection at its output interfaces. 

Thus, as one aspect of the described embodiment, it Is proposed to provide 
enhancements that may be needed in such environments. An l-MPC can 
include an extension in the target resolution to indicate the DS codepoint for the 
flow instigating the request. 

Connection Management 

Shortcut VCCs for flows with different DS code points may require different 
ATM QoS capabilities than UBR. Thus, in the described embodiment,, 
associated with each DS code point is a set of ATM signaling Information 
Elements (lEs), which specify the QoS requirements and traffic parameters that 
are appropriate for that code point. The logic for determining whether to share 
an existing VCC or to establish a new one is similar to MPOA v1 .0. With DS, the 
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ATM signaling lEs associated with the flow's DS Code p int should be used for 
establishing a new VCC. 

Further details regarding a proposed embodiment of the present invention are 
given in Table A below which discusses several issues with implementation of 
DS over MPOA and proposed solutions: 
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1 

2 TABLE A 

3 

4 ISSUES 

5 Issue 1: 

6 With MPOA, the packet forwarding part of a router Is distributed to the 

7 MPCs for packets that are forwarded over shortcuts. This implies that a router 

8 must also share its Diff-Serv roles (per-hop behaviors, edge behaviors) with its 

9 MPCs. In other words, MPCs must have access to the relevant Diff-Serv policy, 

10 Otherwise shortcut forwarding would continue to use the default UBR VCCs for 

1 1 all packets, bypassing the appropriate Diff-Serv treatments. 

12 Diff-Serv policy has several aspects. All nodes, interior and edge, must 



13 know the relationship between the DS field of a packet and the appropriate PHB. 

14 When transmitting over links with QoS abilities such as ATM, this may Include a 

15 mapping between the DS Codepoint (DSCP) and specific link layer QoS 

16 parameters. Additionally, edge nodes must know the rules for packet 

17 classification, metering, policing, marking, and shaping (the policy decides if an 

18 edge node should perform some, all, or none of these functions). 

19 An MPS at a Diff-Serv interior node needs to forward to its MPCs the 

20 mapping between the DSCPs and ATM signaling parameters (i.e., QoS and 

21 traffic descriptor lEs). Edge policy, on the other hand, can be far more complex. 

22 Diff-Serv policy for edge nodes can be expressed as a collection of filter 

23 specifications. A filter specification is a combination of filter criteria and filter 

24 actions. Filter criteria define how packets should be classified. They are 

25 generally based on certain header fields (e.g., source IP address, destination IP 

26 address, earned protocol, source port, and destination port). Filter actions define 

27 how packets should be marked and treated by edge nodes. 
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1 Furthermore, there are two related questions that also need to b 

2 addressed: the issue of policy distribution timing (i.e., when a policy must 

3 become available at the MPCs) and the issue of policy changes and updates. 
4 

5 Issue 2: 

6 In MPOA v1.0, the default detection of shortcut-eligible IP flows is based 

7 on the count of packets sent to a particular destination through a particular MPS 

8 in a specified period of time. With Diff-Serv QoS, packets for the same 

9 destination may be of different Diff-Serv categories and therefore would require 

10 multiple ATM VCCs (e.g., VCCs that are signaled with different Virtual Class 

11 Selector IE.) The definitions of flows and shortcut-eligibility must therefore be 

12 clarified and enhanced. For example, should packets to the same destination 

13 but with different DSCPs be considered as multiple separate flows or one flow? 

14 What definitions are chosen would have some implication on the subsequent 

15 steps of target resolution and VCC establishment. Although MPOA v1,0 permits 

16 other flow detection procedures, interoperability concerns dictate a standard 

17 default flow detection method for Diff-Serv capable MPCs. 
18 

19 Issue 3: 

20 With Diff-Serv, an l-MPC may need to convey to the E-MPC the DSCP of the 

21 flow (or flows) that prompted the target resolution process. Some of the 

22 important applications include: 

23 When different DSCPs need to be mapped to different IEEE 802.1 D 

24 user_priority markings in the DLL header for frames departing from the E- 

25 MPC. In this case, the layer 2 encapsulation at the egress is dependent on 

26 the DSCP. 
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1 - When an E-MPC wants to use different MPOA tags for different DSCPs to aid 

2 egress queue selection at its output interfaces. With different MPOA tags, 

3 the E-MPC avoids needing to reexamine the DS field in the packet header for 

4 output queue selection. 

5 This requirement suggests that the target resolution process needs to 

6 accommodate extensions for Diff-Serv in the control messages. Note that other 

7 fields in a packet besides the DSCP may be needed by the egress to determine 

8 the correct DLL/tag. Such fields need to be transmitted to the egress during the 

9 resolution process. 
10 

11 Issue 4: 

12 Two Diff-Serv domains can be interconnected by a boundary node, which 

13 performs any necessary re-marking and/or traffic shaping of packets. When 

14 multiple Diff-Serv domains are supported over a single ATM network cloud (e.g., 

15 in an enterprise network with logical departmental boundaries to observe 

16 different Diff-Serv policies), there is a problem with MPOA shortcuts spanning 

17 Diff-Serv domains: packets over the shortcuts bypass the boundary node and do 

18 not get reclassified. This requires MPOA to be aware of the Diff-Seiv domain 

19 boundary, or for the MPOA Diff-Serv solution to be defined for intra-domain 

20 differentiated services only. 
21 

22 Issues,; 

23 In order to continue to support plug-n-play operation, the discovery protocol 

24 must be enhanced to support the automatic discovery of the QoS capabilities of 

25 neighboring MPOA devices. 
26 
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PROPOSED SOLUTIONS 

Policy Distribution 

There are several approaches for an MPC to obtain its relevant DS policy; 

1. The MPC can obtain policy in the same manner as its MPS, such as running 
a policy distribution protocol to receive policy directly from a server, or being 
configured by the network management system. 

2. The policy can be distributed during configuration via the LECS. 

3. The policy can be distributed during MPOA discovery. 

4. A new request/response/trigger procedure between MPCs and MPSs can be 
defined to distribute this information. 

The first method greatly increases the number of policy clients, and may 
affect the scalability of the policy distribution protocol. Additionally, it requires 
MPCs to have an IP address to run the policy distribution protocol (which is an 
explicit non-requirement of MPOA v1.0). However, this method requires no 
extensions in the behavior of any other LANE or MPOA component. In methods 
(2) through (4), new TLVs are defined to carry the mappings. The TLVs are 
carried in the appropriate LANE or MPOA control frames. The second method 
requires some out-of-band mechanism to distribute policy to the LANE 
Configuration Server, which then distributes It to the MPCs. With this method, 
there is a difficulty when an MPC has different policies when dealing with 
different MPSs. The third method is dynamic, but may be limited by the size of 
the LANE control frame (which is at most 1516 octets). The final method Is the 
most generic, but requires a new type of MPOA control frame, a policy 
request/response frame. With the last method, the MPC must obtain the policy 
relevant to an IP destination before establishing a shortcut to that destination. 



21 



WO 00/30401 



PCT/US99/26902 



1 Methods (3) and (4) have the advantage that the distribution can be dynamic 

2 (i.e., the mappings can change and the changes are automatically propagated to 

3 the MPCs). 

4 In choosing the distribution method, attention should be placed on the 

5 consideration for edge policy. The distribution of edge policy, in the form of filter 

6 specifications, differs from the distribution of the mappings between DSCPs and 

7 ATM QoS parameters in several aspects. First, the sheer amount of information 

8 in the collection of filter specifications is much greater. There are a limited 

9 number of DS Codepoints, but the number of possible filter specifications is 

10 much greater. Second, it is unlikely that a single MPC will need all of the filter 

1 1 specifications at any time. An MPC needs only those filter specifications that 

12 apply to traffic being forwarded by that MPC. Third, filter specifications are 

13 generally more dynamic and changes in filter specifications must be propagated 

14 in a timely fashion. 

15 

16 Proposed Solution for Policy Distribution 

17 First of all, we assume that filter specifications can apply to a range of 

18 addresses (as specified by either a upper and lower bound, or a destination and 

19 mask). Filter specifications that apply to a single destination are better 

20 distributed to MPCs when traffic to the destination is detected. Filter 

21 specifications that apply to all destinations may be better distributed to all MPCs 

22 immediately upon device detection (without waiting for traffic to be detected). 
Between the two extremes is a range of possibilities. 

As such, it is best left to the MPS to determine when filter specifications 
are distributed to MPCs. MPSs must ensure that all filter specifications that 
apply to a particular destination are distributed to an MPC before it initiates a 
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1 shortcut to the MPC. An MPS may choose any policy distribution algorithm it 

2 desires as long as this requirement is met. Thus, an MPS may choose to 

3 distribute all filter specification to an MPC upon device detection. Alternatively, 

4 an MPS may distribute filter specification to an MPC only upon flow detection. 

5 Many intermediate possibilities exist. 

6 

7 Diff-Serv PHB Policy Distribution and Specification 

8 All MPSs (both Diff-Serv interior and edge nodes) need to forward to their 

9 MPCs the association between each DSCP and a set of ATM QoS and traffic 

10 parameters (an ATM traffic profile), which will be used for signaling shortcut 

1 1 VCCs. They must also provide any necessary mapping to ATM header marking, 

12 such as how to map the drop preference bits used in Assured Forwarding for the 

13 three drop preference levels to CLP bit for the ATM cells. 
14 

15 We propose that 

16 • A new request/response/trigger procedure between MPCs and MPSs for 

17 distribution of Diff-Serv PHB policy. An initial request/response should be 

1 8 made immediately after an MPS and an MPC discover each other. 
19 

20 The PHB policy specification should contain the following fields: 

21 Table 1. Contents of PHB policy specification 



Name 


Description 


DSCP mask 


identify which of the 6-bit DS field are 
significant 


DSCP 


Bit pattern for Diff-Serv Codepoint 
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CLP marking 


How a packet's drop preference Indicated by 
this DS Codepoint should be mapped to the 
CLP marking in ATM header. 


ATM Signaling lEs (one or 
more IE, each with three 
sub-fields) 


As defined in UNI specifications 


IE Identifier 




Length 




Contents of IE 





1 



2 Each PHB policy specification TLV thus Identifies one PHB through the 

3 pair of DSCP and DSCP mask. The ATM signaling IE fields are used when a 

4 new VCC needs to be established for carrying flows with this DSCP. The CLP 

5 marking field determines how the packet-to-cell adaptation should mark the ATM 

6 cells. As an example, a PHB group called Assured Forwarding (AF) utilizes 12 

7 Codepoints for 4 AF classes, each with 3 drop precedences. Suppose the 4 AF 

8 classes are to be mapped to 4 virtual classes within the ATM UBR category, 

9 which are denoted here as Profile 1 through Profile 4. Also suppose the medium 
JO and high drop precedences are mapped to CLP=1 . The PHB policy specification 

1 1 for each of the 1 2 DSCPs may be: 

12 Table 2. An example of how the PHB policy specifications express the 

13 PHB-to-ATM QoS mapping. 



DSCP 


DSCP 


ATM Signaling 


CLP 


Mask 




lEs 


marking 


111110 


010000 (class 1, low) 


Profile 1 


0 


111110 


010010 (classl, 


Profile 1 


1 
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DSCP 
Mask 


DSCP 


ATM Signaling 
lEs 


CLP 
marking 




medium) 






111110 


010100 (class 1, high) 


Profile 1 


1 


111110 


011000 (class 2, low) 


Profile 2 


0 


111110 


011010 (class 2, 
medium) 


Profile 2 


1 


111110 


011100 (class 2, high) 


Profile 2 


1 


111110 


100000 (class 3, low) 


Profile 3 


0 


111110 


100010 (class 3, 
medium) 


Profile 3 


1 


111110 


100100 (class 3, high) 


Profile 3 


1 


111110 


101000 (class 4, low) 


Profile 4 


0 


111110 


101010 (class 4, 
medium) 


Profile 4 


1 


111110 


101100 (class 4, high) 


Profile 4 


1 



Diff-Serv Edge Policy Distribution and Specification 

An MPS at a Diff-Serv edge node must also distribute its filter 
specifications to its MPCs. As mentioned before, the solution must account for 
(1) the total volume of the filters, (2) their dynamic nature with policy changes, 
and (3) the fact that not all MPCs need all filters. An MPC only need those filters 
relevant to the packets it is forwarding. 

Hence a solution capable of dynamic filter specification downloading is most 
desirable. We propose 
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1 

2 > A new request/response/trigger procedure between MPCs and MPSs for 

3 distribution of packet classification and treatment policy. 
4 

5 In the following we outline one approach for such procedure, with the 

6 objective of ensuring that all filters relevant to an IP destination are available at 

7 an l-MPC prior to any shortcut establishment for that destination by the l-MPC. 

8 This assumes that the l-MPC is associated with a Diff-Serv edge router: 



9 

10 1 . Initial filter specifications: An MPC requests from the MPS an initial filter 

11 set upon MPOA discovery. The MPS may return some or all filters 

12 specifications at its discretion. 
13 

14 2. Other filter specifications: An MPC initiates filter request/response for a 

15 specific IP destination address after the number of packets it receives for 

16 this destination exceeds a threshold and before it initiates an MPOA 

17 Resolution Request for this destination. The MPC may then use a second 

18 threshold to determine when to initiate a MPOA Resolution Request. 
19 

20 3. Policy changes: The MPS triggers an MPC to issue a filter request when 

21 there is a policy change. An MPS only needs to update those MPCs to 

22 which the filter specification applies. 
23 



24 We propose that 
25 

26 > The filter specifications from MPS to MPC used to communicate Diff-Serv 

27 edge policy should contain the following components and sub-fields: 
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1 

2 Table 3. Contents of edge policy specification 



Name 


Description 


Filter Operation 


Specify what operation to be applied with this 
filter. 


Filter Preference 


Priority the filter relative to other filters in the 
case of multiple filter matches. 


Filter Criteria (contains the 
following sub-fields) 


Criteria used for packet classification 


Ingress Interface 




Source IP Address 




Destination IP Address 




Carried Protocol 




Source Port 




Destination Port 




DS Field 




Filter Actions (one or more 
variable-length components 
expressed in TLV) 


A flag Identifying the action (such as 
shaping, policing, etc.), possibly followed by 
a number of variable-length parameters 
associated with the action (e.g., policing 
parameters). 



3 



4 Rlter Operation indicates to the MPC what to do with this given filter. For 

5 example, operations may include install, delete, update, replace, enable, or 

6 disable. Edge policy may be specified such that a packet satisfies multiple filter 
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1 criteria cached at an MPC. To identify the appropriate filter actions to use, the 

2 filter specifications should be communicated with a relative preference. 
3 

4 Configuration and Discovery 

5 To provide for interoperability with MPOA V1.0 implementation, we 

6 propose conveying Diff-Serv and Int-Serv capabilities in the discovery procedure. 

7 An absence of associated TLV(s) indicates that the device does not support the 

8 specific QoS capability. 
9 

10 Proposal: 

1 1 ♦ New TLV(s) should be added to the LE^ARP messages to indicate the QoS 

12 capabilities of the device during discovery. 
13 

14 Furthermore, other TLV(s) may also be added to indicate specific supports. 

15 For example. DS parameter distribution (e.g., sen/Ice weights in a CBQ), 

16 methods of filter specification distribution, whether policy distribution is enabled, 

17 whether an MPS is a DS edge router, etc. 
18 

19 Flow Detection 

20 As mentioned in Issue 2 above, the definition of "shortcut eligible flow" needs to 

21 be refined with QoS. We propose to adopt the following: 
22 

23 > For Diff-Serv traffic, flow detection uses a <MPS ATM Address, IP 

24 Destination Address, DS Codepolnt> tuple. Flow detection definition and 

25 algorithms must be adjusted for the Diff-Serv codepoint 
26 
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1 In other words, ingress cache entries In MPCs should be extend d to monitor 

2 the DS field. With this definition, packets with the same IP destination but 

3 different OS Codepoints will be treated as separate flows as they correspond to 

4 separate ingress cache entries. Note that this is applicable whether the l-MPS is 

5 an edge or an interior node in its Diff-Serv domain. If multi-field packet 

6 classification is required, It must be done prior to the ingress cache lookup. 

7 With dynamic edge policy distribution, the policy associated with a destination 

8 may not be at an ingress MPC prior to the initial arrivals of packets for that 

9 destination. This can be addressed by a two-stage flow detection. In the first 

10 stage, the l-MPC counts the number of packets with a particular destination 

1 1 address and MPS as if they are best-effort packets (DSCP = default). When this 

12 count exceeds a threshold, the MPC initiates a filter request. Upon receiving the 

13 applicable filter specifications, the l-MPC can perform flow detection including 
H the DS Codepoint, based on the filter specifications returned. 

15 Assume that an MPC is performing the edge device functions for a particular 

16 MPS and that it has requested and received the filter specifications applicable to 

17 a certain packet. When another matching packet arrives at the l-MPC, it is 

18 matched against the filter specifications to determine its DS Codepoint. The 

19 result, together with the destination address and MPS, is used to match with the 

20 ingress cache entries, or to create a new entry if one does not already exist. If a 

21 match is found and a shortcut VCC of the appropriate QoS is available, the I- 

22 MPC applies the corresponding filter actions before forwarding the packet over 

23 the shortcut. Otherwise, a flow detection counter is incremented and the packet 

24 is forwarded to the l-MPS, and no edge functions are performed by the MPC. If 

25 the configured flow threshold is exceeded, a shortcut with the appropriate QoS 

26 class is initiated. If the MPC is not performing edge router functions, the DS 

27 Codepoint of the packet is used to match the ingress cache entry. 
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Target Resolution 

To address the needs for conveying DS Codepoints of flows to the E-MPCs 
(i.e., Diff-Serv Issue 3), we propose adding new extensions to the MPOA control 
message formats. Specifically, we propose that: 

> A new MPOA QoS Extension is defined for the MPOA Resolution 
Request/Response to carry flow identification information. A possible format 
is as follows; 



Field 


Usage 


Type 


This field must be set to Ox — (TBD) for MPOA DSCP 
Extension 


Length 


variable 


Value 


Filter criteria identifying traffic that will use this VCC 



The propagation of this extension in other message formats (e.g., from 
NHRP Resolution Reply to MPOA Resolution Reply) is the same as other 
extensions. Note that this extension is not intended to be adjusted by 
intermediate routers but is intended to provide information to the egress MPOA 
devices so that the correct DLL and tag can be chosen for egress traffic. 

In this case one DSCP extension is associated with each instance of target 
resolution (i.e., each unique <MPS ATM Address, IP Destination Address, DS 
Codepoint can initiate one target resolution). Hence if an E-MPS/E-MPC is 
capable of choosing a unique egress cache tag and/or a unique DLL header for 
each DS Codepoint, the values in the Egress Cache Tag Extension and/or the 
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1 DLL Header Extension in its MPOA Cache Imposition Reply will be uniquely 

2 associated with the Codepoint carried in the DSCP Extension. 
3 

4 Signaling and Connotf fan Management 

5 For Diff-Serv traffic, the DS Codepoint serves as the label that associates a 

6 Diff-Serv flow with a QoS VCC shortcut. In other words, an l-MPC should only 

7 forward a flow with a given DSCP over a VCC shortcut if the VCC is established 

8 using the signaling lEs given in the PHB policy specification for this DSCP. 

9 
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CLAIMS 

What is claimed is: 

1 . A method of providing Internet Protocol differentiated services using 
Multiprotocol Over ATM (MPOA) shortcuts providing for policy distribution 
through MPOA. 

2. The method as recited by claim 1 wherein MPOA clients execute a policy 
distribution protocol to receive policy. 

3. The method as recited by claim 1 wherein policy is distributed to MPOA 
clients by a LAN emulation configuration server. 

k The method as recited by claim 1 wherein policy is distributed to MPOA 
clients during a discovery process. 

k The method as recited by claim 1 wherein the policy is distributed to 
MPOA clients by MPOA servers using a request response protocol. 

A method of distributing policy parameters in a network comprising the 
steps of: 

a) distributing policy information to MPOA servers; and 

b) distributing the policy information to MPOA clients. 
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7. The method as recited by claim 6 wherein the policy is used by MPOA 
clients to determine mapping of packets to differentiated sen/ice code 
points, to determine resource allocation and to determine packet 
metering, policing, marking and shaping. 

8. A method of determining whether an IP flow is eligible for an MPOA 
shortcut comprising: 

a) a device determining the number of packets N sent with a DS code 
point P during a period of time T; and 

b) if N exceeds a value, the device determining the IP flow is eligible for 
an MPOA shortcut. 

9. The method as recited by claim 8 wherein the device stores DS code 
point information in an ingress cache. 

1 0. A method of determining whether an IP flow Is eligible for an MPOA 
shortcut comprising: 

a) tracking packets sent with a DS code point by a device; and 

b) determining eligibility for an MPOA shortcut based on a predetermined 
criteria associated with tracking of packets sent with the DS code 
point. 
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1 1 . The method as recited by claim 1 0 wherein the tracking comprises 
determining the number of packets N sent with the DS code point during a 
period of time T. 

12. The method as recited by claim 10 wherein the step of determining 
eligibility comprises determining if the number N exceeds a value. 

13. The method as recited by claim 10 wherein ingress cache entries in the 
device include DS code point information, 

14. A device for routing information in a network, the device including an 
ingress cache, the ingress cache storing DS code point information for 
packets received by the device. 

15. A method of distributing filter specifications from a MPOA server to MPOA 
. clients in a network comprising: 

a) distributing filter information which applies to a single IP destination to 
an MPOA client when traffic to the IP destination is detected at the 
MPOA client; 

b) distributing filter information which applies to a range of IP destinations 
to an MPOA client in accordance with rules for the MPOA server; and 

c) distributing filter information which applies to all IP destinations when 
a new MPOA client is detected. 
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16. The method as recited by claim 1 5 wherein the filter information which 
applies to a range of IP destinations is distributed to a particular MPOA 
client before initiation of a shortcut for one of the IP destinations by the 
MPOA client. 

1 7. The method as recited by claim 1 5 wherein the filter information which 
applies to a range of IP destinations is distributed when a new MPOA 
client is detected. 

18. The method as recited by claim 15 wherein the filter information which 
applies to a range of IP destinations is distributed when traffic to one of 
the IP destinations is detected at an MPOA client. 

1 9. A method of detecting whether a device is capable of performing 
differentiated services comprising: 

a) receiving a message from a device; 

b) determining if the message includes elements encoded in type length 
value format indicating differentiated service capability; and 

c) if the message Includes such type length values, determining the 
device is capable of performing differentiated servfces. 

20. The method as recited by claim 19 wherein the type length values indicate 
whether the device is an IP Differentiated Services edge device. 
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21 . The method as recited by claim 19 wherein the type length values indicate 
whether the device has policy distribution capabilities enabled. 

22. The method as recited claim 1 9 wherein the type length values Indicate 
whether the device has filter specification distribution enabled. 

23. The method as recited by claim 19 wherein the type length values indicate 
whether the device has differentiated service parameter distribution 
enabled. 

24. A method of updating filter specifications from an MPOA server to MPOA 
clients in a network comprising: 

a) the MPOA server receiving filter specification updates from a policy 
server; 

b) the MPOA server triggering MPOA clients to initiate filter request; 

c) the MPOA clients initiating filter requests upon receiving a trigger 
from the MPOA server; and 

d) the MPOA clients updating its filter specifications upon receiving 
filter responses from the MPOA server. 
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